System and Method of Rack Management

ABSTRACT

A rack management method and system is disclosed. The method includes detecting the presence of a computing device releasably mounted in a frame, the detecting based on an electrical connection established between a configuration bar disposed in a rear portion of the frame and the computing device, and determining a physical location of the computing device within the frame based on the electrical connection. The method also includes retrieving management information about the computing device from a profile storage disposed within the computing device via the electrical connection and storing the management information in a management table, the management table associating the computing device with the physical location within the frame.

CROSS-REFERENCE

This application is a continuation of U.S. patent application Ser. No.13/830,191, filed on Mar. 14, 2013, the entirety of which is herebyincorporated by reference

BACKGROUND

The present disclosure relates generally to rack management, and moreparticularly to systems and methods for management of computing devicesmounted in a rack system.

Data centers with hundreds or thousands of computing devices often mountsuch computing devices into racks for organizational and spaceefficiency purposes. A single rack may contain a plurality of servers, aplurality of storage devices, one or more network appliances to connectthe devices to a network, and a power supply to power the devices.Traditionally, computing devices mounted within a rack have beenindividually managed, for instance, with a keyboard and monitorphysically attached to the devices, or remotely via baseboard managementcontrollers within the devices. Although, management solutions have beendevised that aggregate control over the computing devices in a rack,such solutions lacked functionality with respect to power management,thermal management, redundancy in the event of control hardware failure,and device detection and configuration. Accordingly, although existingrack management methods and structures have been satisfactory for theirintended purposes, they have not been entirely satisfactory in allrespects.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a functional block diagram of a rack system including a rackmanagement controller (RMC) according to aspects to the presentdisclosure.

FIG. 2 is a functional block diagram of the rack management controllerof FIG. 1.

FIG. 3 is a functional block diagram of various components of the racksystem including the RMC and the interconnections therebetween.

FIG. 4 is a simplified illustration of an example management tablemaintained by the RMC that stores management information about computingdevices in the rack system.

FIG. 5 is a functional block diagram of various components of the racksystem of FIG. 1 including the RMC and a configuration bar.

FIG. 6 is a functional block diagram of an alternative embodiment ofportions of the rack system of FIG. 1 including the RMC and theconfiguration bar.

FIG. 7 is a simplified flow chart describing a method of initiallyconfiguring computing devices within the rack system.

FIG. 8 is a simplified flow chart describing a method for managing totalpower usage of the computing devices within the rack system of FIG. 1.

FIG. 9 is a simplified flow chart describing a method for managingthermal characteristics of the computing devices within the rack systemof FIG. 1.

FIG. 10 is a functional block diagram of a high-availability rackmanagement system according to aspects of the present disclosure.

FIG. 11 is a simplified flow chart describing a method for managing racksystems in a high-availability network according to aspects of thepresent disclosure.

SUMMARY OF THE INVENTION

In one exemplary aspect, the present disclosure is directed to a rackmanagement method. The method includes detecting the presence of acomputing device releasably mounted in a frame, the detecting based onan electrical connection established between a configuration bardisposed in a rear portion of the frame and the computing device, anddetermining a physical location of the computing device within the framebased on the electrical connection. The method also includes retrievingmanagement information about the computing device from a profile storagedisposed within the computing device via the electrical connection andstoring the management information in a management table, the managementtable associating the computing device with the physical location withinthe frame.

In another exemplary aspect, the present disclosure is directed to arack management system. The system includes a frame configured tosupport computing devices releasably mounted therein, a configurationbar disposed in a rear portion of the frame, the configuration barhaving a first coupling assembly, and a computing device releasablymounted within the frame such that a second coupling assembly disposedon the computing device is releasably coupled to the first couplingassembly, an electrical connection being established between the firstcoupling assembly and the second coupling assembly. The system alsoincludes a profile storage disposed within the computing device thatstores management information about the computing device, and a rackmanagement controller in electrical communication with the computingdevice via the electrical connection and being configured to retrievethe management information from the profile storage via the electricalconnection.

In a further exemplary aspect, the present disclosure is directed to arack system. The system includes a frame configured to support computingdevices releasably mounted therein and a configuration bar disposed in arear portion of the frame. The system also includes a computing devicereleasably mounted within the frame such that the computing device isreleasably coupled to the configuration bar, an electrical connectionbeing established between the computing device and the configuration barand a profile storage disposed within the computing device that storesmanagement information about the computing device. Further, the systemincludes a rack management controller having a non-transitory,computer-readable storage medium that stores a plurality of instructionsfor execution by at least one processor. The instructions includeinstructions to detect the presence of the computing device within theframe based on the electrical connection and instructions to determine aphysical location of the computing device within the frame based on theelectrical connection. The instructions also includes instructions toretrieve management information about the computing device from theprofile storage via the electrical connection and instructions to storethe management information in a management table, the management tableassociating the computing device with the physical location within theframe.

DETAILED DESCRIPTION

For the purposes of promoting an understanding of the principles of thepresent disclosure, reference will now be made to the embodimentsillustrated in the drawings, and specific language will be used todescribe the same. It is nevertheless understood that no limitation tothe scope of the disclosure is intended. Any alterations and furthermodifications to the described devices, systems, and methods, and anyfurther application of the principles of the present disclosure arefully contemplated and included within the present disclosure as wouldnormally occur to one skilled in the art to which the disclosurerelates. In particular, it is fully contemplated that the features,components, and/or steps described with respect to one embodiment may becombined with the features, components, and/or steps described withrespect to other embodiments of the present disclosure. For the sake ofbrevity, however, the numerous iterations of these combinations will notbe described separately

Referring now to FIG. 1, illustrated is a functional block diagram of arack system 100 according to aspects of the present disclosure. The racksystem 100 is comprised of a plurality of discrete computing devices andincludes a frame 102 in which the computing devices are releasablymounted. The frame 102 has standardized dimensions such that any pieceof hardware that conforms to the rack standards may be mounted therein.In that regard, the frame 102 includes a plurality of virtual partitions104 that extend the width of the frame 102 and are of equal height 106.In certain embodiments, each partition 104 has a height of 48 mm and awidth of 537 mm, but, in other embodiments, each partition may have adifferent height such as 44.45 mm and may have a different width such as482.6 mm. Each partition 104 may be referred to as a rack unit or uSpaceand the height of rack-mountable computing devices may be measured inthe number of rack units they occupy. For example, a computing devicemay occupy 1 rack unit, 0.5 of a rack unit, or 3 rack units. In theexample embodiment of FIG. 1, a server 108 is mounted in the frame 102and is 1 rack unit in height, whereas a server 110 is 2 rack units inheight. Further, the frame 102 is configured to allow up to threeindividually-powered computing devices to be mounted side-by-side withinone of the virtual partitions 104. In that regard, each partition 104 issegmented into three equally-sized power zones 112. Each power zone 112is associated with a power bar 114 that is disposed at the rear of therack and provides power to a computing device mounted in the power zoneand coupled thereto. The power bars 114 extend the height of the frame102 and are energized by a power shelf 116 mounted in the frame. In oneembodiment, the power shelf 116 outputs 12 volts DC to each power bar114, but, in other embodiments, the power shelf may output a differentDC voltage or may output an AC voltage. Further, in some embodiments,the rack system 100 may include a battery backup system that energizesthe power bars in the event that the power shelf fails or ceases toreceive power from an external source. In such a scenario, backupbatteries may be mounted within the frame 102, or backup batteries maybe housed in locations remote to the rack system 100. Additional detailsabout the power bars 114 and power management of the rack will bediscussed in association with FIG. 4.

The frame 102 of the rack system 100 further includes a configurationbar 118 respectively disposed in each of the three power zones 112. Eachconfiguration bar 118 runs parallel to a respective one of the powerbars 114 and is configured to couple to a computing devices mountedwithin the frame 102. As such, when a computing device is mounted in theframe 102, it is in electrical communication with one or more of thepower bars 114 and is also coupled to one or more of the configurationbars 118. As will be described in more detail in association with FIG.5, the configuration bars provide data planes through which computingdevices report their physical location within the frame 102 and reporthardware configuration and attribute information so that they may becentrally managed.

The rack system 100 includes a rack management controller (RMC) 120 thatis configured to monitor, control, and otherwise manage computingdevices mounted in the frame 102. In general, the RMC 120 collectsmanagement information associated with each of the rack-mountedcomputing devices and performs rack-related management tasks based onthe information. To efficiently and accurately perform such managementtasks, the RMC 120 maintains real-time records describing the locations,configurations, and tolerances of the computing devices mounted in therack system 100. Example management tasks carried out by the RMC 120 mayinclude operational status monitoring of computing devices within therack system, power and cooling management of the rack devices, on-demandhardware provisioning, failover services for other rack managementcontrollers, error logging, and other such management tasks. The RMC 120further provides a central point of access (i.e., a gateway) throughwhich management communications associated with the computing devices inthe rack system 100 may be routed, viewed, and/or aggregated. Thevarious management capabilities and hardware configurations of the RMC120 will be discussed in greater detail in association with theremaining figures.

In the illustrated embodiment of FIG. 1, the RMC 120 monitors andmanages the servers mounted in the frame 102, such as servers 108 and110, also manages other types of computing hardware in the rack systemsuch as storage devices 122 and a network switch 124. In someembodiments the RMC 120 is operable to provide interfaces through whichthe switch 124 may be remotely initially configured. In alternativeembodiments, the network switch 124 may be replaced with or augmentedwith other network communication hardware such as a router or a bridge.The storage devices 122 may be any type of devices that providepersistent storage for the servers on the rack system or otherremotely-located systems. For example, in one embodiment, each storagedevice 122 may be a chassis that holds a plurality of hard drives thatare either independently addressable (i.e., “just a bunch of disks” orJBOD) or concatenated and presented as a single storage unit. In otherembodiments, the storage devices 122 may form a RAID-based storagesolution or may be legacy storage devices such as tape drives. The RMC120 is configured to perform various power, configuration, andmonitoring-related functions with respect to the storage devices 122.

One of ordinary skill in the art would recognize that the illustratedembodiment of FIG. 1 is simply an example embodiment and the rack systemmay include additional and/or different features, devices, capabilities,etc. For instance, the dimensions of frame 102 set forth herein aresimply example dimensions and the frame may take on any number ofphysical configurations depending on the environment in which the racksystem is deployed. The computing devices mounted within the frame 102are similarly just examples, and any additional and/or different typesof computing devices and accessories may be mounted in the frame. Forexample, blade servers, database controllers, network routers, patchpanels, backup batteries, diagnostics equipment, graphics processorarrays, hard drive controllers, and any other rack-mountable computingequipment or peripheral that conforms to the rack unit height standard106 may be mounted in the frame 102. However, as described below, to befully managed by the RMC 120, a server or other computing device shouldcouple to at least one of the power bars 114 and at least one of theconfiguration bars 118 when mounted in the frame 102.

Referring now to FIG. 2, illustrated is a functional block diagram ofthe rack management controller (RMC) 120 of FIG. 1 according to aspectsto the present disclosure. Referring also to FIG. 3, illustrated is afunctional block diagram of various components of the rack system 100including the RMC 120 and the interconnections therebetween according toaspects to the present disclosure. In the illustrated embodiment of FIG.2, the RMC 120 is a printed circuit board with mounting hardwareconfigured to attach it to the frame 102 of the rack system 100.However, in other embodiments, the RMC 120 may have other form factorssuch as that of an adapter card within a computing device, afull-featured server mounted in the frame, an expansion board, or anyother suitable form factor either mounted within or independent of theframe. In any case, as shown in FIG. 2, the RMC 120 includes a pluralityof components that together are configured to monitor, control, andotherwise manage computing devices mounted in the frame 102.

In more detail, the RMC 120 includes a logic module 150 that isconfigured to perform data processing tasks, computation tasks, routingtasks, and/or other similar tasks for the RMC. In one embodiment, thelogic module 150 is a system-on-a-chip (SoC) that includes a low-powermicroprocessor such as an ARM-based or Atom-based processor. As a SoC,the logic module 150 further includes on-board random access memory(RAM), peripherals such as timers, and external communication interfacessupporting communication protocols such as Ethernet, Universal SerialBus (USB), Universal Asynchronous Receiver/Transmitter (UART), FireWire,serial peripheral interface (SPI), and System Management Bus (SMBus). Inother embodiments, the logic module 150 is a discrete microprocessor andother system components are independently disposed on the RMC 120.Additionally, in one embodiment, the logic module 150 executes anembedded operating system such as embedded Linux. The operating systemmay be stored on a non-transitory, computer-readable storage 152 tofacilitate execution of computer instructions by the processor. Thestorage 152 may be a solid-state storage device, a hard disc, an opticaldisk, a magneto-optical disc, and/or a variety other mass storagedevices known in the art. The storage 152 may be embedded within thelogic module 150 or it may be independently disposed on the RMC 120. Inthe illustrated embodiment, the storage 152 further stores hardwareattribute information and operational status information about thecomputing devices in the rack system 100. The RMC 120 stores andretrieves the configuration and operational information from the storage152 as necessary to manage the components of the rack system 100. Aswill be discussed in association with FIG. 4, in one embodiment, thelogic module 150 maintains a management table in which suchconfiguration and operational information is tracked and updatedaccording to the components installed in the frame 102.

Referring now to both FIGS. 2 and 3, the RMC 120 is interconnected tovarious components internal and external to the rack system 100. First,the RMC 120 includes one or more management ports 154 through which theRMC manages the computing devices on the rack system 100. In certainembodiments, one of the management ports 154 may be a primary port andthe other may be a failover or backup port. In the illustratedembodiment, the management ports 154 are Ethernet-based andcommunicatively couple the RMC to a network 156. The network 156 may beany type of network such as a local area network (LAN), a wide-areanetwork (WAN), the Internet, an intranet, a management-type networkwithin a data center, or any other type of network known in the art. Asshown in FIG. 3, the computing devices of the rack system 100 such asservers 158, 160, 162, and 164 and storage devices 122 are alsocommunicatively coupled to the network 156 via the switch 124. The RMC120 communicates with out-of-band or in-band management modules (e.g.,baseboard management controllers, etc) within the servers 158, 160, 162,and 164 and storage devices 122 via the management ports 154. In oneembodiment, the RMC 120 communicates with and manages the computingdevices in rack system 100 using Data Center Manageability Interface(DCMI) for out-of-band management, but, in other embodiments, the RMCmay use another management standard such as Intelligent PlatformManagement Interface (IPMI), Desktop and mobile Architecture for SystemHardware (DASH), Remote Management Control Protocol (RMCP), or acombination thereof. As an example, the RMC 120, via the managementports 154, may be able to remotely perform at least the followingmanagement tasks: power up, power down, or power cycle a computingdevice; query operational status information such as temperature andpower usage of a computing device; alter the power usage of a computingdevice (e.g., by varying a processor clock speed); alter the speed of aninternal fan of a computing device; select a boot image for a computingdevice; access and change BIOS settings of a computing device; redirecta computing system's input/output via console redirection; access anevent log stored on a computing device; query the hardware and softwareinventory of a computing device; receive event notifications from acomputing system. One of ordinary skill in the art would recognize thatthe above list is not limiting and the RMC 120 may perform various otheradditional and/or different management tasks associated with thecomputing devices in the rack system 100.

The logic module 150 executes the procedures and algorithms to implementthe above management tasks. It does so based on configuration andoperational status information associated with the computing devicesstored in the storage 152. For example, the RMC 120 may periodicallyrequest power usage information from each computing device and store thereceived information in the storage 152. The logic module 150 may thentake some management action based on the individual or aggregate powerusage of the devices in the rack system 100. FIGS. 8 and 9 describe inmore detail management methods performed by the RMC 120 related to rackpower usage and rack thermal management, respectively. Further,management actions executed by the logic module 150 may be based uponthe individual hardware characteristics and physical location of deviceswithin the rack. Such information may be stored in storage 152 in amanagement table, as will be discussed in association with FIG. 4.

The RMC 120 further includes a console port 170 that is communicativelycoupled to a management port of the network switch 124. In theillustrated embodiment, the console port 170 is a RS232 serial port thatis configured to pass commands to and receive console output from aconsole serial port on the switch 124. The logic module 150 is furtheroperable to route console I/O to the network 156 via the managementports 154. In this manner, the RMC 120 is operable to facilitate remotemanagement of the switch by allowing a computing device not physicallyconnected to the switch's console port to send commands to and receivedata from the console port via the network 156. In certain embodiments,the RMC 120 may include a plurality of console ports 170 thatrespectively connect to multiple console-managed devices, such asrouters, servers, and other switches.

In the rack system 100, some or all of the computing devices are cooledby fans external to the computing devices themselves. The RMC 120 isfurther configured to control such fans. In that regard, the RMC 120includes a fan control port 172 that is communicatively coupled to oneor more fan controllers 174 via a communication pathway 176 such as asystem management bus (SMBus), an Inter-Integrated Circuit (PC) bus, alow pin count (LPC) bus, a serial-type bus, or any other type of wiredor wireless bus known in the art. As shown in FIG. 3, each fancontroller 174 controls a fan 178 that cools one or more computingdevices mounted in the frame 102. For example, in the example embodimentof FIG. 3, servers 158 and 160 are cooled by the same fan 178 andservers 162 and 164 are cooled by the same fan 178. The logic module 150within the RMC 120 is operable to monitor the thermal properties of thecomputing devices in the rack system 100 and control the fans associatedwith the computing devices in response to the detected thermalproperties.

Because the fans 178 are independent of the computing devices in theframe 102, the RMC 120 stores management information that maps eachcomputing device to a specific fan and manages fan speeds based on themanagement information. In that regard, FIG. 4 is a simplifiedillustration of an example management table 180 maintained by the RMC120 that stores management information about computing devices in therack system 100, including information that associates the computingdevices with the fans assigned to cool them. In more detail, themanagement table 180 associates physical locations within the frame 102with the computing devices and fans that are located within them. Forexample, the management table 180 includes information about each uSpacein the frame 102 and each power zone within each uSpace. As shown in theexample of FIG. 4, the management table 180 indicates that server 1 ismounted in uSpace 0/power zone 0 and that fan1 cools server 1. Devicesand fans may span multiple uSpaces and/or power zones. For instance,server4 is mounted in both power zone 0 and 1 of uSpace 1 as indicatedin management table 180. Further, as mentioned above, a single fan maycool more than one computing device. For example, management table 180associates fan1 with both server1 and server4. In this manner, when theRMC 120 detects that a specific computing device in the rack system 100needs additional cooling, it may utilize location information stored inthe management table 180 to determine which fan needs to be speedadjusted.

In addition to associating a computing devices within the rack system100 with physical locations within the frame 102, the management table180 further stores hardware and operational characteristics of computingdevices and fans in the rack system. The RMC 120 performs managementtasks based upon such hardware characteristics information incombination with the physical location information described above. Asan aspect of this, the management table 180 stores thermal attributesand fan control algorithm information associated with the computingdevices in the rack system 100. That is, a computing device may haveassociated with it information dictating how much airflow a fan coolingthe computing device should be outputting when the device is betweenvarious temperature thresholds. In the example of FIG. 4, the managementtable 180 may store a fan control algorithm (e.g., a pulse-widthmodulation (PWM) algorithm, etc) for server1 that dictates the speeds atwhich fan1 should be operating or the airflow fan1 should be producing.As such, in the event the RMC 120 detects that the heat produced server1 is between two temperature thresholds, the RMC can set fan1 to operateat the speed dictated by the fan control algorithm stored in themanagement table 180. In some embodiments, the RMC 120 may be configuredto perform additional computations related to fan control, such as fanspeed to airflow computations based on fan and hardware characteristics.Additional fan control methods carried out by the RMC 120 will bediscussed in association with FIG. 9.

As mentioned above, the management table 180 stores hardware andoperational characteristics of computing devices in the rack system 100.In certain embodiments, the management table 180 may store for eachcomputing device in the rack system some or all of the followinginformation: physical location (uSpace, power zone, etc), device size(in physical dimensions and/or number of uSpaces, etc), device type(server, storage, switch, etc), device manufacturer and model, deviceboot priority (respective to other devices in the rack system), devicehardware assets (processor type, memory amount, internal storage amount,peripherals, etc), device thermal attributes, device power usage, devicefan control algorithms, device MAC address, device IP address, baseboardmanagement controller (BMC) IP address, BMC software type and version.One of ordinary skill in the art would recognize that the above list isnot limiting and the management table 180 may store various otheradditional and/or different information associated with the computingdevices in the rack system 100. Methods and systems to initiallyconfigure and populate the management table 180 with configurationinformation will be discussed in association with FIGS. 5-7. Further oneskilled in the art would recognize that the RMC 120 may store andorganize information about computing devices within the rack system 100in a variety of manners and the management table 180 is simply oneexample embodiment. Moreover, the structure of management table 180shown in FIG. 4 is simply illustrative and the data represented by themanagement table may be stored by the RMC 120 in a variety of ways. Inalternative embodiments, the RMC 120 may store location, hardware, andoperational information about computing devices in one or more differentand/or additional data structures such as in database tables, memoryarrays, vectors, flat files, linked lists, hash tables, or any otherdata structures known in the art.

With reference back to FIGS. 2 and 3, the RMC 120 further includes twoor more high-availability ports 186 that are respectivelycommunicatively coupled to a failover RMC 188 and a failover RMC 190that are disposed in other rack systems. During normal operations, RMC120 and failover RMCs 188 and 190 each manage their own rack systems,but, in the event one of the RMCs fails, one or more of the remainingRMCs takes over management of the failed RMC's rack system to effecthigh-availability operations. In the illustrated embodiment, eachhigh-availability port 186 is coupled to one of the failover RMCs via acommunication link 192. In one embodiment, the communication link 192 isa low-bandwidth signaling link such as a SMBus link or serial link, but,in other embodiments, the communication link 192 is another type of linksuch as an Ethernet-based or wireless link. The logic module 150 isconfigured to transmit periodic messages (i.e., heartbeats) to thefailover RMCs 188 and 190 to indicate that the RMC 120 is alive andoperational. The logic module 150 similarly receives heartbeats from thefailover RMCs 188 and 190 to indicate that they are alive andoperational. In the event RMC 120 detects that it is no longer receivingheartbeats from either of the failover RMCs 188 and 190, the RMC 120 isconfigured query whether the failover RMC has actually failed, and, ifso, begin managing the computing devices normally managed by the deadRMC. Additional details associated with the high-availability aspects ofthe RMC 120 are discussed in association with FIGS. 10 and 11.

In the illustrated embodiment of FIG. 2, the RMC 120 further includes aconfiguration port 192 that is communicatively coupled to theconfiguration bars 118 (FIG. 1), which are, in turn, coupled to some orall of the computing devices within the rack system 100. The RMC 120,via the configuration bars 118, is configured to detect when a newcomputing device is inserted into the frame 102, determine the physicallocation of the new computing device within the frame, and retrievehardware configuration and attribute information from the new computingdevice. The physical location information and hardware configuration andattribute information are stored in the management table 180 so that theRMC 120 may perform computing device-specific management tasks that aredependent on physical location and hardware information.

In more detail, FIG. 5 is a functional block diagram of variouscomponents of the rack system 100 including the RMC 120, one of theconfiguration bars 118, one of the power bars 114, two servers 200 and202 within the rack system, and interconnections therebetween accordingto aspects to the present disclosure. More specifically, FIG. 5illustrates the manner in which RMC 120 determines the physical locationand hardware attributes of computing devices, such as servers 200 and202, within the frame 102. As discussed in association with FIG. 1, theframe 102 includes the configuration bars 118 to which computing devicescouple when they are inserted into the frame. More specifically, foreach slot within the frame 102 that a distinct computing device may beinserted (e.g., three slots per horizontal uSpace in the example of FIG.1), the configuration bar 118 includes a blind-mating, bar couplingassembly. Computing devices configured for use in the rack system 100each include a complementary device coupling assembly that mates with arespective one of the bar coupling assemblies when it is inserted intothe frame 102. In the example of FIG. 5, the configuration bar 118includes bar coupling assemblies 204 and 206 and the servers 200 and 202respectively include device coupling assemblies 208 and 210. When adevice coupling assembly is mated with a bar coupling assembly, anelectrical connection is established and information about the computingdevice having the device coupling assembly, including its location, istransmitted through a communication link to the RMC 120. Morespecifically, in the illustrated embodiment, the bar coupling assembly204 includes a sense contact 212 and data contacts 214, and the devicecoupling assembly 208 includes a complementary sense contact 216 andcomplementary data contacts 218. When an electrical connection is madebetween the sense contact 212 in the bar coupling assembly and the sensecontact 216 in the device coupling assembly, an electrical signal isdetected by the RMC 120 via the configuration port 192. The RMC 120 isconfigured to detect from which bar coupling assembly the electricalsignal originated, wherein each bar coupling assembly is associated witha different physical location in the frame 102. The configuration port192 includes sensing hardware that determines the origin of electricalsignals generated by the sense contacts when a device is coupled to theconfiguration bar. In one embodiment, each bar coupling assembly may bemapped to a cell of the management table that represents a physicallocation within the frame 102. In this manner, the RMC 120 is operableto determine when a computing device has been inserted into the frameand the physical location of the computing device. In alternativeembodiments, the RMC 120 may determine the physical location of acomputing device within the frame using the bar coupling assemblies indifferent manners. For instance, in some embodiments, the bar couplingassembly and device coupling assembly may lack the sense contacts. Insuch embodiments, the RMC 120 may utilize the data contacts to bothdetermine a location of a computing device and also retrieve informationfrom the device's profile storage. For example, when a new computingdevice is mounted in the frame 102 and an electrical connection isestablished by the engagement of the data contacts within the couplingassemblies, the RMC 120 is configured to (1) use the existence of theelectrical signal to detect from which bar coupling assembly theelectrical signal originated (and thus determine the physical location),and (2) use the data-carrying capacity of the electrical signal toretrieve the management information from the device's profile storage.

FIG. 6 illustrates a functional block diagram of an alternativeembodiment of portions of the rack system 100 including theconfiguration bar 118 and RMC 120. Specifically, FIG. 6 is directedtoward a further alternative structure for determining the physicallocation of a computing device within the frame 102. Like theconfiguration bar of FIG. 5, the configuration bar 118 of FIG. 6includes bar coupling assemblies 230 and 232 that respectively mate withdevice coupling assemblies 234 and 236 on servers 200 and 202. However,the bar and device coupling assemblies shown in FIG. 6 each include aplurality of binary contacts rather than a single sense contact. Inparticular, the bar coupling assembly 230 includes binary contacts 238that form a pattern representing a binary number that uniquelyidentifies the location of the bar coupling assembly 230 in the frame102. In the example of FIG. 6, the bar coupling assembly 230 hascontacts at binary positions 2 and 4 representing the number 001010. Thebar coupling assembly 232 similarly includes binary contacts 240 thatform a different binary number that identifies the physical location ofthe bar coupling assembly 232. The device coupling assemblies 234 and236 on the servers 200 and 202 also include binary contacts 242 244 buteach includes contacts at every binary position. That is, when barcoupling assembly 230 is mated with the device coupling assembly 234,electrical connections will only be established at the binary positionsrepresented by the binary contacts 238 within the bar coupling assembly230. The binary number represented by the selective electricalconnections is thus transmitted to the RMC 120, which maps the binarynumber to a specific physical location within the frame 102. Thus, whena computing device is inserted into the frame 102 and it mates with theconfiguration bar 118, the RMC is configured to detect both the presenceof a new computing device and its physical location without additionallogic at the configuration port 192.

Referring now back to FIG. 5, when a device coupling assembly is matedwith a bar coupling assembly, a further electrical connection isestablished via the data contacts. For example, when device couplingassembly 208 mates with bar coupling assembly 204, the data contacts 214electrically couple with the data contacts 218. The resultingcommunication pathway is used to transfer hardware configuration andattribute information about a computing device to the RMC 120 forinsertion into the management table 180. In that regard, the datacontacts in the bar coupling assemblies may be communicatively coupledto the RMC 120 through a low-bandwidth communication link 219 such as aserial link (e.g., a RS232 link), an SMBus link, or a USB link. In otherembodiments, the communication link 219 may be another type ofcommunication link such as an Ethernet connection or a wirelessconnection. As an aspect of this, the computing devices configured foruse in the rack system 100 each include a small amount of non-volatilestorage that contains hardware configuration and attribute informationabout the computing device. In one embodiment, a computing devicemanufacturer programs the hardware configuration and attributeinformation into the computing device's profile storage before shippingthe device. In the illustrated embodiment of FIG. 5, the server 200includes a profile storage 220 and the server 202 includes a profilestorage 222. For example, the profile storage 220 may store thefollowing information about the server 200: device size (in physicaldimensions and number of uSpaces, etc), device type (server, storage,switch, etc), device manufacturer and model, device hardware assets(processor type, memory amount, internal storage amount, peripherals,etc), device power up and power down timing, device thermal attributes,device power usage, device fan control algorithms, device MAC address,baseboard management controller (BMC) IP address, BMC software type andversion. One of ordinary skill in the art would recognize that the abovelist is not limiting and the profile storage in various computingdevices may store additional and/or different information. As describedabove, when the server 200 is inserted into the frame 102 and the devicecoupling assembly 208 mates with bar coupling assembly 204, the sensecontacts 212 and 216 make an electrical connection that informs of theRMC 120 of the presence and location of the computing device 200. Uponsuch detection, the RMC 120 is configured to retrieve the informationstored in the profile storage 220 of the server 200 via thecommunication path established by the data contacts 214 and 218.

One of ordinary skill in the art would recognize that the physicalcomponents depicted in the FIG. 5 have been simplified for illustrationpurposes and may not represent their actual physical forms. Forinstance, the device coupling assemblies 208 and 210 and the barcoupling assemblies 204 and 206 may take on a variety of physical formsand may establish electrical connections between the RMC 120 and servers200 and 202 in a variety of manners, for instance, through electricalpins, sockets, plugs, magnets, latches, and the like.

Further, the system described above in FIG. 5 for extracting hardwareconfiguration and attribute information from a newly-inserted computingdevice may be configured in various manners in alternative embodiments.For example, the transfer of hardware configuration and attributeinformation from a newly-inserted computing device to the RMC 120 may beaccomplished over a short-range wireless connection, such as aradio-frequency (RF) connection or a Bluetooth connection. Specifically,in one embodiment, each computing device to be inserted in to the racksystem 100 may include a RF chip that stores information about theassociated computing device in place of a profile storage device. Suchan RF chip may be disposed internally or externally to a computingdevice chassis. Additionally, in such an embodiment, the bar couplingassemblies on the configuration bar may be replaced with RF sensors thatread the device information stored in the RF chips when computingdevices are inserted into the frame 102. The RF sensors would thentransmit the extracted information wirelessly or over wireline to theRMC 120. To associate an RF sensor with a specific slot in the frame 102(i.e., uSpace/power zone), each RF sensor would only be configured todetect RF chips disposed within its associated slot. In this manner, theRMC 120 could detect via each RF sensor whether each slot in a rackframe is occupied or empty. The RMC could also determine the location ofa specific computing device based on the identity and location of the RFsensor its RF chip is associated with. In some instances, thisshort-range wireless system would permit older rack systems to beretrofitted to work with the RMC 120 and its configuration table.

As mentioned above, the RMC 120 is configured to monitor the operationalstatus of computing devices in the rack system 100. As an aspect ofthis, the RMC is operable to detect and report hardware failure eventsreported by the computing devices in the rack system, for instance, viatheir baseboard management controllers. Errors detectable by the RMC mayinclude processors overheating, fan failures, memory errors, and othersimilar errors known in the art. When hardware-based events occur acrossthe devices in the rack system, the RMC is operable to aggregate theerrors and take some action to efficiently inform system administrators.For instance, the RMC may forward an aggregate error report to amanagement engine operating at a level higher than the RMC, for example,at the data center level. Further, in some embodiments, the RMC may beconfigured to autonomously take action based on a given error event. Forinstance, if a server reports a critical, internal fault, the RMC mayboot up another server inside the rack so it can take over the functionsof the failing server. In such a scenario, the RMC may alternativelysend an alert to a larger management construct that would, in response,start a new server provisioning process that would spin up a replacementserver for the one that failed.

Referring now to FIG. 7, illustrated is a simplified flow chartdescribing a method 250 of initially configuring computing deviceswithin the rack system 100. The method 250 begins at block 252 where theRMC 120 monitors the rack system for insertion of new computing devicesinto the frame 102. As described in association with FIG. 5, the RMC 120is configured to detect when an electrical connection is made betweenone or more contacts in a bar coupling assembly on the configuration bar118 and one or more contacts in a device coupling assembly of acomputing device. If a new computing device has been detected indecision block 254, the method 250 continues to block 256 where the RMC120 determines the physical location of the new computing device withinthe frame 102. As discussed in association with FIGS. 5 and 6, the RMC120 may both detect the presence and determine the physical location ofcomputing devices by the electrical connections formed when a computingdevice is coupled to the configuration bar 118. In the embodiments inwhich the bar coupling assemblies include a single sense contact, theRMC 120 determines the physical location of a computing device based onthe specific electrical connection incoming to the configuration port192. In other embodiments in which the bar coupling assemblies includecontact patterns that represent binary numbers, the RMC 120 determinesphysical location of a computing device based on the specific binarynumber transmitted to the RMC when the computing device is coupled tothe configuration bar 118.

After the physical location of a newly-inserted computing device isdetermined, the method 250 moves to block 258 where the RMC 120 queriesthe profile storage in the computing device for hardware configurationand attribute information describing the device. As mentioned above,this profile information may include data about power usage, thermalcharacteristics, fan control algorithms, and other such information asdescribed above. Next, in block 260, the RMC 120 adds the hardwareconfiguration and attribute information retrieved from the new computingdevice to the management table 180, which associates the informationwith a physical location in the frame 102. Finally, to complete theinitial setup of a new computing device inserted in to the rack system100, the RMC 120 associates the fan that cools the computing device withthe device in the management table 180. As such, when the managementtable 180 includes physical location, hardware configuration andattribute information, and fan information, the RMC 120 is operable toremotely monitor, command, and otherwise manage the new computingdevice. In that regard, as shown in block 264 of method 250, the RMC 120manages the device using the information stored in the management table180 and also information retrieved from a baseboard managementcontroller (BMC) on the computing device. For instance, the RMC 120 mayretrieve real-time temperature status information from the computingdevice's BMC and manage the fan associated with the computing devicebased on fan control algorithms retrieved from the device through theconfiguration bar 118 and stored in the management table 180. One ofordinary skill in the art would recognize that the method 250 ofinitially configuring computing devices within the rack system 100 issimply an example and the method may include additional and/or differentblocks. For instance, the method 250 may include additional stepsdepending on the type of computing device is detected by the RMC 120.

Referring now back to FIG. 5, the some or all of computing devicesmounted in the frame 102, such as servers 200 and 202, are powered bythe power bar 114. As described in association with FIG. 1, the powershelf 116 energizes the power bar 114, which in turn, powers individualdevices that are coupled to the power bar. In the illustrated embodimentof FIG. 5, the power bar 114 includes a blind-mating, hot-pluggable barpower coupler for each slot within the frame 102 that a distinctcomputing device may be inserted (e.g., three slots per horizontaluSpace in the example of FIG. 1). Computing devices configured for usein the rack system 100 each include a complementary device power couplerthat mates with a respective one of the bar power couplers when it isinserted into the frame 102. In the example of FIG. 5, the power bar 114includes bar power couplers 270 and 272 and the servers 200 and 202respectively include device power couplers 274 and 276. When a devicepower coupler is mated with a bar power coupler, an electricalconnection is established and power modules 278 within the servers 200and 202 draw the power needed to operate the servers.

As an aspect of this, the RMC 120 is operable to perform a variety ofpower management tasks associated with the computing devices within therack system 100. The RMC 120 does so through management modules 280 inthe servers 200 and 202, which expose out-of-band managementfunctionality to management controllers like the RMC. In one embodiment,the management modules 280 are baseboard management controllers (BMCs)such as Intel® Management Engines, but in other embodiments, themanagement modules 280 may be other types of controllers known in theart. Further, the management modules 280 may be different in differentcomputing devices within the rack system 100. The RMC 120 is operable tocommunicate with the management modules 280 through the network 156 andnetwork modules 282 within the servers 200 and 202. As discussed above,the RMC 120 is configured to remotely power up, power down, power cycle,put into standby, wake up from standby, and vary a processor clock speedof a computing device via its management module 280. The RMC 120leverages this out-of-band functionality to perform a variety of powermanagement tasks associated with the computing devices within the racksystem 100.

For instance, the RMC 120 is operable to control the sequence and timingof the startup and shutdown of computing devices drawings power from thepower bar 114. To avoid a large power draw due to all computing devicesin a rack system powering up at once, the RMC 120 may stagger thestartup times of the devices. For example, in a simple embodiment, theRMC 120 may insert delays of specific times between sending power upsignals to various computing devices. However, in other embodiments, theRMC 120 may determine power up times and sequences dynamically based onthe types, dependencies, and priorities of devices within the rack. Forexample, the RMC 120 may build a startup vector (or other datastructure) that defines sequence and timing using the information storedin the management table 180, including physical location and hardwareconfiguration and attribute information. In one embodiment, a startupvector is built with priority information stored in the management table180, with different types of devices having different priority levels.For instance, network switches may have a top priority indicating thatthey should be powered on before any other devices in a rack, storagedevices (e.g., JBODs) may have a medium priority level, and servers mayhave a low priority level to indicate that they should be powered onafter any storage devices. Moreover, the management table 180 mayadditionally include information describing the startup times of thedevices in the rack. For instance, the management table 180 may indicatethat a database server may take five minutes to reach a ready stateafter given an initial power-on signal from the RMC 120. In oneembodiment, the priority level and startup timing information about acomputing device may be pre-determined by a manufacturer and stored inthe device's profile storage, such that the information is inserted intothe management table 180 when the device is first mounted in the rack.In certain embodiments, priority levels of specific computing devicesmay customized by a user after the priority information has beeninserted into the management table 180, for instance, to change theorder in which specific devices start up. As such, in an exemplaryembodiment, when the RMC 120 receives a command to power up all devicesin the rack system, it queries the management table 180 for priority andstartup time information associated with each device and dynamicallybuilds a startup vector that defines the sequence and timing of when theRMC should send power up signals to the devices.

A further power-related management task performed by the RMC 120 isintelligently provisioning computing devices in an on-demand hardwareenvironment (i.e., metal-as-a-service (MAAS)). For instance, in oneembodiment the rack system 100 includes a plurality of computing devicesthat are interchangeable resources in a scalable compute cloud. In suchan embodiment, the RMC 120 is configured to intelligently select whichcomputing device in the rack should be powered on in response to anincoming resource request. If multiple machines within a rack may beused to fulfill a resource request, the RMC 120 applies one or morecriteria to choose which machine to power on. In one example, the RMC120 selects computing devices based on their physical location withinthe frame 102, as described in the management table 180. In that regard,it may be advantageous to power-on machine that are closest to a coolingsource, as computing devices run more efficiently at coolertemperatures. In the example of traditional data centers, cool air mayemanate from the floor, so the RMC 120 may preferably power-on thecomputing device most near to the bottom of the frame 102.

The RMC 120 may additionally utilize other criteria to select whichcomputing device in the rack should be powered-on in response to anincoming resource request. For instance, such a selection may be basedon run-time hours of the computing devices in the rack system 100. Inone embodiment, the RMC 120 selects computing devices so as todistribute run-time hours evenly across the rack system 100. When aresource request is received by the RMC 120, it queries either themanagement modules of the computing devices or the management table 180to determine the run-time hours of the device, and, in one example,selects the device with the least number of run-time hours. Such aprovisioning criteria may prolong the average life of computing devicesin the rack system 100. One of ordinary skill in the art would recognizethat various other criteria may be utilized by the RMC to intelligentlyselect a computing device in response to a resource request.

In addition to provisioning bare metal hardware resources for on-demandcomputing, the RMC is also operable in one embodiment to provisionvirtual resources within the computing devices in the rack system underits management. For instance, an on-demand computing system may requestthat a new virtual machine instance should be instantiated on acomputing device within the rack system 100. The RMC 120 is configuredto dynamically select the specific computing best suited for the virtualmachine. Using hardware attribute information contained in themanagement table 180 and also real-time operational status informationretrieved from the computing devices' BMCs, the RMC 120 may choose acomputing device based on a variety of criteria. For instance, the RMC120 may first select the plurality of computing device within the racksystem 100 that meet the hardware requirements of the virtual machine.Out of this subset of devices, the RMC 120 may then select the devicethat is operating at the lowest temperature to host the virtual machine.Any number of additional criteria may be utilized by the RMC to select avirtual machine host. As an aspect of this, because the RMC 120maintains hardware attributes of each device in its managed rack, theRMC may create device-appropriate deployment scripts for operatingsystems being deployed within the rack system.

The RMC 120 further is operable to monitor the aggregate power usage ofthe computing devices within the rack system 100 and perform managementtasks in response. In one embodiment, the RMC 120 is configured to set atotal power usage limit for the rack system 100 and dynamically takeactions to reduce power usage if the limit has been exceeded. It may beadvantageous to cap the power usage of a rack to some amount lower thanfull load to create power usage vs. compute power efficiencies. Forinstance, the total wattage drawn by a rack system under full load maybe 11,748 watts, but by imposing a limit at 10,000 watts, a significantamount of power may be saved, and any resultant performance hit may benegligible. In that regard, FIG. 8 is a simplified flow chart describinga method 284 for managing total power usage of the computing deviceswithin the rack system 100. In more detail, the method 284 begins atblock 286 where an upper threshold for aggregate power usage of thecomputing devices within the rack system 100 is established. In someembodiments, the RMC 120 automatically sets the upper threshold based onfactors such as the power output capability of the power shelf 116 (FIG.1), power usage vs. compute power efficiency data, and/or a variety ofother factors. But, in other embodiments, a rack administrator maymanually set a power usage threshold, for example, through a userinterface exposed by the RMC 120. Next, in block 288, the RMC 120monitors real-time power usage of each of the computing devices withinthe rack system. As mentioned above, the RMC 120 is operable to querythe management modules (e.g. BMCs) of the computing devices for theirreal-time power usage data. In some embodiments, the RMC 120 stores theretrieved power usage information in the management table 180 inassociation with the respective computing device.

The method 284 then proceeds to block 290 where the RMC 120 aggregatesthe power usage information to determine the total power usage of therack system. In some embodiments, a total power usage calculation may beperformed at periodic intervals during operation of the rack system 100,but, in other embodiments, the RMC 120 may maintain a running totalpower usage number that is updated in real-time when additional powerusage data is retrieved from individual computing devices. In decisionblock 292, the calculated total power usage is compared to the upperpower usage threshold. If the calculated usage is below the threshold,the method 284 returns to block 288 and the RMC 120 continues to monitorthe power usage of the individual computing devices. If instead thecalculated usage is above the threshold, the method 284 proceeds toblock 294 where the RMC 120 dynamically selects one or more devices as apower reduction target. The RMC 120 may apply various criteria todetermine for which device or devices power usage should be reduced suchthat total power usage of the rack is lowered below the threshold. Forinstance, the RMC 120 may select power reduction targets based on thecurrent thermal characteristics of the computing devices, as monitoredthrough the devices' BMCs. In such an embodiment, the RMC may select thecomputing devices that are running at temperatures above their normaloperating temperatures, or it may select computing devices based ontheir temperature relative to other similar devices in the rack (i.e.,select the server with the highest temperature processor). In otherembodiments, the RMC 120 selects power reduction targets based onpriority level or run-time hours maintained in the management table 180(i.e., a server with a low priority will be selected before a serverwith a high priority). After one or more power reduction targets havebeen selected in block 294, the method 284 proceeds to block 296, wherepower usage of the selected targets is reduced until the total powerusage of the rack system is below the threshold. The RMC 120 may reducepower usage in a variety of manners. For instance, if servers 200 and202 in FIG. 5 are selected as power reduction targets, the RMC 120 maystep down the clock speed of the respective processor modules 297 and298 via their management modules 280. In one embodiment, the RMC 120 mayselect most or all of the computing devices in the rack system 100 thathave speed-adjustable processors, and decrease operating speed of eachdevice a small (i.e., negligible) amount so as to spread out thenecessary power drop across the rack system, rather than subjecting afew devices to significant power drops and the resultant performancehits. In other embodiments, when the total power usage is significantlyabove the upper threshold, the RMC 120 may power-down the selectedcomputing devices. After actions to curtail power usage by the selectedcomputing devices have been made, the method 284 returns to block 288where the RMC 120 continues to monitor the power usage of the computingdevices in the rack system 100. One of ordinary skill in the art wouldrecognize that the method 284 for managing total power usage of thecomputing devices within the rack system 100 is simply an example andthe method may include additional and/or different steps.

Referring now to FIG. 9, illustrated is a simplified flow chartdescribing a method 300 for managing thermal characteristics of thecomputing devices within the rack system 100. Specifically, method 300describes a management task performed by the RMC 120 to adjust fan speedin the embodiments in which fans are external to and independent of thecomputing devices and a single fan may be assigned to cool multiplecomputing devices. (see FIG. 3). The method 300 begins at block 302where the RMC 120 monitors real-time thermal characteristics of thecomputing devices within the rack system 100. As mentioned above, theRMC 120 is operable to query the management modules (i.e., BMCs) of thecomputing devices for their individual temperature data. In someembodiments, the RMC 120 stores the retrieved thermal information in themanagement table 180 in association with the respective computingdevice. Next, in block 304 the RMC 120 applies the fan controlalgorithms of each computing device (as stored in the management table180) to the temperature data collected in block 302. Specifically, asdescribed above in association with FIG. 4, each computing device mayhave associated with it information dictating how much airflow a fancooling the computing device should be outputting based on a devicetemperature. For example, the management table 180 may store apulse-width modulation (PWM) algorithm for a server that dictates thespeeds at which a PWM-based cooling fan should be operating or theairflow the fan should be producing. For each computing device, the RMC120 applies the PWM algorithm to the current device temperature todetermine an appropriate fan speed for the fan associated with thecomputing device. As mentioned above, the management table 180 maps thecomputing devices in the frame 102 to the fans cooling them.

In decision block 306, the RMC 120 determines whether the fan associatedwith a first computing device is operating at the appropriate calculatedspeed. In the embodiment of FIGS. 2 and 3, the logic module 150 of theRMC 120 makes this determination by querying the fan controllerassociated with the fan via the communication pathway 176. If thecurrent fan speed is approximately equal to the calculated speed, themethod 300 returns to block 302 and the RMC 120 continues to monitor thethermal characteristics of the rack devices. If a fan speed adjustmentis needed based on the thermal information gathered from the firstdevice, the method 300 proceeds to decision block 308 where the RMCdetermines whether the first device shares the fan with another deviceusing the fan-to-device mapping of the management table 180. If the fanexclusively cools the first device, the method proceeds to block 310where the fan speed is adjusted to the speed calculated in block 304.If, however, the first device shares the fan with a second device, thenthe method continues to block 312 where the RMC 120 applies the seconddevice's fan control algorithm to the current temperature of the seconddevice to determine an appropriate fan speed for a fan cooling thesecond computing device. Next, in block 314, the RMC 120 sets the fanspeed to the higher of the speed calculated for the first device inblock 304 and the fan speed calculated for the second device in block314. In this manner, when two or more devices share the same fan, thecomputing device with the highest airflow demands will be adequatelycooled. One of ordinary skill in the art would recognize that the method300 for managing thermal characteristics of the computing devices withinthe rack system 100 is simply an example and may include additionaland/or different steps. For instance, the RMC 120 may perform any numberof additional calculations to determine an adequate fan speed forcomputing devices, such as calculations necessary to account to ambienttemperature and fan size. Further, portions of the method 300 may berepeated depending in the number of computing devices cooled by the samefan.

In alternative embodiments, each computing device may itself manage theexternal fan cooling it. In such embodiments, a computing device'sbaseboard management controller may monitor its temperature and send asignal to the RMC when a fan speed control change is needed. Uponreceiving the speed change request, RMC would determine from themanagement table which fan is mounted adjacent to the computing deviceand forward the request on to the correct fan controller. In the casethat conflicting fan speed requests are received from computing devicesthat share a fan, the RMC would defer to the computing device with thegreater cooling needs, in a manner similar to that illustrated above inFIG. 9.

Referring now to FIG. 10, illustrated is a functional block diagram of ahigh-availability rack management system 400 according to aspects of thepresent disclosure. As discussed in association with FIGS. 2 and 3, theRMC 120 that manages rack system 100 is backed-up by one or morefailover RMCs that each manage their own respective rack system. And, inthe event that RMC 120 fails, one of the failover RMCs will take overmanagement of the rack system 100. In the illustrated embodiment of FIG.10, the RMC 120 in rack system 100 is backed-up by failover RMCs on aplurality of other rack systems 402, 404, 406, 408, and 410. Asdescribed in association with FIG. 3, the RMC 120 is physically coupledto RMCs in rack systems 402 and 410 via the communication link 192.However, the RMC 120 is communicatively coupled to RMCs in rack systems404, 406, and 408 via the rack systems 402 and 410 for form ahigh-availability network. This ring-style communication network enablesany of the RMCs in rack systems 100, 402, 404, 406, 408, and 410 to takeover management of any other RMC. As one aspect of this, each RMC in thehigh-availability network includes a copy of management tables from eachof the other RMCs in the network. As such, when a RMC fails, another RMCcan manage the failed RMCs rack system using the correct managementtable. Although FIG. 10 illustrates a separate low-bandwidthcommunication link 192 communicatively coupling the RMCs, allhigh-availability tasks (e.g., heartbeats, failover) may bealternatively performed over the network 156 that interconnects the racksystems. Additional details of the high-availability failover processare discussed in association with FIG. 11.

In that regard, FIG. 11 is a simplified flow chart describing a method420 for managing rack systems in a high-availability network accordingto aspects of the present disclosure. The method 420 begins at block 422where management tables of RMCs within the high-availability network arereplicated across the network. That is, each RMC in the network hascopies of the management tables from the other RMCs in the network. Inone embodiment, management table replication occurs periodically on aschedule so that the RMCs have up-to-date copies of the others'management tables. In other embodiments, replication is event driven.For example, an RMC will initiate replication of its management tableafter a new computing device has been inserted into its rack system andthe device's physical location and hardware information has been addedto the management table. The method 420 next proceeds to block 424 wherethe RMCs exchange heartbeats over the communications link 192 to informeach other of their operational status. In some embodiments, theheartbeats are simple pings, but, in other embodiments, the heartbeatsmay include additional information such as operational statistics. In afurther embodiment, each heartbeat transmitted by a RMC includes a copyof its management table that can be stored by the other RMCs. Eachmanagement table received in a heartbeat from a specific RMC wouldreplace the management table received in the previous heartbeat from thesame RMC. As such, when a heartbeat is no longer detected from a failedRMC, the replicated management table associated with that failed RMCwill be up-to-date as of the last heartbeat received from the failedRMC.

In decision block 426, a first RMC determines whether it is receivingheartbeats from every known RMC in its high-availability network. If itis, the first RMC continues to monitor for heartbeats in block 424. Ifthe first RMC instead detects that it is no longer receiving heartbeatsfrom a second RMC, then the method 420 proceeds to block 428 where thefirst RMC attempts to contact the second (silent) RMC over the network156 (for example, by pinging its management port) and inquire as to itsstatus. In decision block 430, if the second RMC responds, the methodproceeds to block 432 where the first and second RMCs begin exchangingheartbeats over the network 156 (as opposed to the communication link192). An error is logged indicating a problem with the communicationlink 192. If, however, the second RMC does not respond, the method 420continues to block 434 where the first RMC begins managing the deviceson the rack system previously managed by the second RMC. As an aspect ofthis, the first RMC loads into memory the management table previouslyreplicated from the second RMC. This enables the first RMC to discoverthe IP address of the BMCs of the computing devices in the rack systempreviously managed by the second RMC. The management table of the secondRMC also includes the physical location and hardware attributes ofcomputing devices in the second RMC's rack, which the first RMC may useto remotely perform management tasks via the network 156. The first RMCcontinues to manage the computing devices in its own rack system. In oneembodiment, as part of the failover process, the first RMC sends analert to system administrators indicating that the second RMC hasfailed. In the embodiments in which a logic module within an RMCdirectly manages fan controllers within the rack system to control fanspeed (see FIGS. 2 and 3), a remote RMC that takes over control of afailed RMC may not have control of the fan controllers, as they are notindependently accessible through the network 156. In those embodiments,the method 420 proceeds to block 436 where the first RMC continuouslymonitors the thermal characteristics of the devices within the failedRMC's rack system. If the first RMC detects that the temperature of adevice is over a critical threshold, the first RMC will first step downthe processor speed of the device and, if the temperature does not fallbelow the threshold, send a shutdown signal to the device's BMC. In oneembodiment, if a fan controller within a rack system detects that thesystem's RMC has failed—through lack of communication or otherwise—thefan controller will set the fans under its control to a default speed,such as full speed. One of ordinary skill in the art would recognizethat the method 420 for managing rack systems in a high-availabilitynetwork is simply an example and may include additional and/or differentsteps. For instance, an RMC taking over for a failed RMC may perform anynumber of additional actions to ensure the health of the computingdevices previously managed by the failed RMC.

Even though illustrative embodiments have been shown and described, awide range of modification, change and substitution is contemplated inthe foregoing disclosure and in some instances, some features of theembodiments may be employed without a corresponding use of otherfeatures. Accordingly, it is appropriate that the appended claims beconstrued broadly and in a manner consistent with the scope of theembodiments disclosed herein.

1-31. (canceled)
 32. A rack management method, comprising: detecting thepresence of a first computing device releasably mounted in a frame;retrieving, by a rack management controller (RMC), managementinformation about the first computing device from a profile storagedisposed within the first computing device, wherein the managementinformation includes device component control algorithms for controllingdevice components associated with the first computing device;establishing a control profile for the first computing device within theRMC, wherein the control profile is at least in part based upon themanagement information retrieved from the profile storage disposedwithin the first computing device; and monitoring the first computingdevice via the RMC, wherein the RMC uses the device component controlalgorithms to operate a device component associated with the firstcomputing device.
 33. The rack management method of claim 32, furthercomprising: detecting the presence of a second computing devicereleasably mounted in the frame; retrieving, by the RMC, managementinformation about the second computing device from a profile storagedisposed within the second computing device, wherein the managementinformation includes device component control algorithms for controllingdevice components associated with the second computing device;establishing a control profile for the second computing device withinthe RMC, wherein the control profile is at least in part based upon themanagement information retrieved from the profile storage disposedwithin the second computing device; and monitoring both the first andthe second computing devices via the RMC, wherein the RMC uses thedevice component control algorithms associated with the first computingdevice to operate a device component associated with the first computingdevice, and the RMC uses the device component control algorithmsassociated with the second computing device to operate a devicecomponent associated with the second computing device.
 34. The rackmanagement method of claim 33, further comprising changing the operationof a device component associated with the first computing device by theRMC, based upon one of information obtained by monitoring the firstcomputing device, information obtained by monitoring the secondcomputing device, and information obtained by monitoring both the firstand second computing devices.
 35. The rack management method of claim32, further comprising: providing a baseboard management controller(BMC) associated with the first computing device, wherein the BMC isoperable to monitor and/or control a device component associated withthe first computing device, and using the RMC to monitor and/or controlthe device component in place of the BMC associated with the firstcomputing device.
 36. The rack management method of claim 35, whereinusing the RMC to monitor and/or control the device component in place ofthe BMC associated with the first computing device occurs when the BMCassociated with the first computing device fails.
 37. The rackmanagement method of claim 35, further comprising: retrieving, by asecond RMC communicatively coupled to the first RMC, the control profilefor the first computing device; monitoring the first RMC via the secondRMC; and controlling the first computing device via the second RMC ifthe RMC associated with the first computing device fails.
 38. The rackmanagement method of claim 37, wherein the second RMC retrieves thecontrol profile for the first computing device from the first RMC. 39.The rack management method of claim 34, wherein changing the operationof a device component associated with the first computing device by theRMC reduces thermal load across both the first and the second computingdevices.
 40. The rack management method of claim 39, wherein thephysical location of the first and second computing devices is used toevaluate the change in the operation of the device component to reducethe thermal load across both the first and the second computing devices.41. A rack management system, comprising: a frame configured to supportcomputing devices releasably mounted therein; a configuration bardisposed in a rear portion of the frame, the configuration bar having afirst coupling assembly and a second coupling assembly; a firstcomputing device releasably mounted within the frame such that a thirdcoupling assembly disposed on the first computing device is releasablycoupled to the first coupling assembly, an electrical connection beingestablished between the first coupling assembly and the third couplingassembly; a second computing device releasably mounted within the framesuch that a fourth coupling assembly disposed on the second computingdevice is releasably coupled to the second coupling assembly, anelectrical connection being established between the second couplingassembly and the fourth coupling assembly; a first profile storage thatstores first management information about the first computing device,wherein the first management information includes first device componentcontrol algorithms for controlling device components associated with thefirst computing device; a second profile storage that stores secondmanagement information about the second computing device, wherein thesecond management information includes second device component controlalgorithms for controlling device components associated with the secondcomputing device; and a rack management controller (RMC) communicativelycoupled with the first and second computing devices, the RMC configuredto: retrieve the first and second management information; store theretrieved first and second management information in a management table;and perform management tasks associated with the first computing devicebased on the management information including the first device componentcontrol algorithms stored in the management table.
 42. The rackmanagement system of claim 41, wherein the management table associatesthe first computing device with a physical location within the frame.43. The rack management system of claim 41, wherein the RMC is furtherconfigured to perform management tasks associated with the secondcomputing device based on the management information including thesecond device component control algorithms stored in the managementtable.
 44. The rack management system of claim 43, wherein the RMC isfurther configured to perform management tasks associated with the firstcomputing device using one of information obtained from devicecomponents associated with the first computing device, informationobtained from device components associated with the second computingdevice, information obtained from device components associated with boththe first and second computing devices.
 45. The rack management systemof claim 44, wherein the physical location of the first computing deviceis discoverable based upon the coupling of the first and third couplingassemblies, and wherein the physical location of the second computingdevice is discoverable based upon the coupling of the second and fourthcoupling assemblies.
 46. The rack management system of claim 45, whereinthe management tasks associated with the first computing device varyaccording to the relationship of the physical location of the firstcomputing device and the physical location of the second computingdevice.
 47. The rack management system of claim 45, wherein themanagement tasks associated with the first computing device reducethermal load associated with the second computing device.